home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group01b.txt / 000088_icon-group-sender_Thu Jul 5 08:58:19 2001.msg < prev    next >
Internet Message Format  |  2002-01-03  |  2KB
  1. Return-Path: <icon-group-sender>
  2. Received: (from root@localhost)
  3.     by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id f65Fw7c19281
  4.     for icon-group-addresses; Thu, 5 Jul 2001 08:58:07 -0700 (MST)
  5. Message-Id: <200107051558.f65Fw7c19281@baskerville.CS.Arizona.EDU>
  6. Date: Wed, 4 Jul 2001 10:13:14 +0100 (BST)
  7. From: Hugh Sasse Staff Elec Eng <hgs@dmu.ac.uk>
  8. X-Sender: hgs@neelix
  9. To: Art Eschenlauer <art.eschenlauer@sufsys.com>
  10. cc: "'icon-group@CS.Arizona.EDU'" <icon-group@cs.arizona.edu>
  11. Subject: Re: Software testing for Icon?
  12. Errors-To: icon-group-errors@cs.arizona.edu
  13. Status: RO
  14. Content-Length: 1753
  15.  
  16. On Mon, 25 Jun 2001, Art Eschenlauer wrote:
  17.  
  18. > One concern that I expect people to raise with respect to using Icon in the
  19. > "mainstream" is, "Icon cannot be trusted because it does not typecheck
  20. > arguments at compile time.  How can you protect against programmer errors in
  21. > the arguments passed during infrequently-executed invocations?"  I don't
  22.  
  23. This assumes static typing.  This often comes up on the Ruby-Talk list
  24. (See below http://www.ruby-lang.org/ for info on the mailing list, which
  25. can be searched from there.)
  26.  
  27. I think this is true for other dynamic languages.  It is argued that
  28. the flexibility is worth this particular cost, and also that development
  29. is speeded up because of not having to declare everything up front.
  30. No-one has cited studies to support this yet, though.
  31.  
  32. > think that the response (however true) that C++ has compile-time
  33. > type-checking and yet still is notorious for null pointer errors, etc, will
  34. > convince anybody.
  35. > 
  36. > This raises two questions in my mind regarding Icon:
  37. > 
  38. > 1. Should one adopt a "defensive programming style", always checking the
  39. > arguments passed to each routine?
  40.  
  41. The concept of "design by contract" may be useful, even if not implememted
  42. in the language.  You agree to use my function subject to your providing
  43. the right args, and provided you do that I'll give you the correct results.
  44. If you don't provide the right args, then there is nothing in the contract
  45. that forces me to give you the right answer. It is a business model.
  46.  
  47. > 
  48. > 2. What work has been done on developing rigorous software-testing
  49. > methodology for Icon programs?
  50.  
  51. I don't know.  With Icon not being OO, I'm not sure if one can apply
  52. unit testing to it, but it has been done somehow in C, so maybe...
  53. > 
  54. > 
  55.     Hugh
  56.  
  57.